Streaming technologies are used for delivering media, e.g. audio and video, provided by a streaming provider to an end-user such that the media is constantly received by and presented to the end-user. Hypertext Transfer Protocol (HTTP) streaming is a mechanism for sending data from a web server to a web browser. HTTP streaming can be achieved through several mechanisms.
Adaptive HTTP streaming is becoming the dominant content streaming technique. Adaptive Streaming (or Adaptive Bitrate Streaming) is a technique used in streaming multimedia over networks like computer networks. Today's adaptive streaming technologies are almost exclusively based on HTTP and designed to work efficiently over large distributed HTTP networks such as the Internet. In principal, adaptive streaming works by detecting a user's bandwidth in real time and adjusting the bitrate and therefore quality of the audio/video stream accordingly. It requires the use of an encoder which can encode a single source audio/video at multiple bit rates. The player client switches between the different encodings depending on available resources.
A number of different techniques exist such as HTTP Live Streaming (HLS) from Apple™, Smooth streaming (ISM) from Microsoft™ and 3GPP (3rd Generation Partnership Project)/Moving Picture Expert Group (MPEG) Dynamic Adaptive Streaming over HTTP (DASH).
Those adaptive HTTP streaming techniques all have common principles: The client receives the content stream as a sequence of files (as a response to HTTP GET requests), or as a sequence of file chunks (as a result of HTTP GET byte-range requests), which is then decoded and played as a continuous media stream. The Uniform Resource Locators (URLs) of the file sequence are described in a manifest file, which is an .m3u8 playlist in case of HLS, an .ismc file in case of ISM and an .MPD file in case of DASH.
FIG. 1 shows a principle of adaptive HTTP streaming, more particular, reception of media segments.
As shown in FIG. 1, a communication network 100 comprises a server 1001 and a client 1002. In step S1, client 1002 requests the manifest file from the server 1001 by means of a “HTTP GET manifest file” request. In response, server 1001 transmits the manifest file to client 1002. In step S2, client 1002 processes the manifest file and requests, in step S3, the first segment (e.g., with the lowest available media data rate (such as the lowest available quality)), as specified in the manifest file, from server 1001.
In step S4, during download of the manifest file occurring in step S5, the client 1002 measures the download speed and uses this estimation to select, in S6, an appropriate representation (an appropriate quality) for the next (e.g. second) segment. For example, client 1002 selects a medium available media data rate (a medium available quality). In step S7, the next segment is requested by client 1002 with a data rate slightly higher than the media data rate theoretically required by the segment (otherwise, the media like a video may frequently stop playing). In step S8, during the download of the second segment occurring in step S9, client 1002 again measures the download speed.
In short, client 1002 fetches one media segment (or file) after another according to the pre-setting in the manifest file. During file download, client 1002 estimates the available link bitrate (download speed). Depending on the difference between the available link bitrate and the encoded bitrate of the media, and taking into account e.g. the client's capabilities (e.g. screen resolution), the client selects an appropriate quality representation (e.g. slightly lower than the measured link bitrate).
FIG. 2 shows an example of an adaptive HTTP stream.
As shown in FIG. 2, in order to prepare a continuous stream of content for adaptive HTTP streaming, the stream is segmented into media segments (or files) X, . . . , X+2 on the side of the server 1001. Each segment can consist of one or more frames. These media segments are fetched by client 1002 one-by-one as independent files each as a HTTP response from server 1001 in response to a HTTP request from client 1002. Upon receipt, client 1002 can append the received media segments X, . . . , X+2 (which may possess different quality levels) into a continuous stream again. Then, client 1002 can play the segments continuously and thereby provide a continuous stream playout.